This change implies that wheel filename components other than name and version (which have specifications restricting their character sets) can now contain any non-hyphen character. Is this intended?

Values in comapatibility tag fields don’t need to be unescaped (just need to compare them directly to a known compatibility list, so any filesystem-valid cahracters would work. This leaves the build tag. Since it is intended to be used as a tie-breaker using lexical ordering, again, any filesystem-valid cahracters would work.

I guess we can add a rule to limit all those fields to \w+. That’s already what everyone is doing (except the I don’t know any real-world usage of the build tag). But I don’t see much benefit in it, to be honest; the worst thing can happen is someone builds a wheel that can’t be downloaded due to filename restrictions, which project maintainers likely would avoid on their own anyway.

@dholth Do you know what values they're using for the build tag?

https://pypi.org/project/cffi/1.14.3/#files

I'm confused. This is a standards track PEP from 2012 that has status "final". It is my understanding that you can't just amend that in place based on one thread on Discourse. I don't recognize any of the names in that thread. Has the packaging WG said anything about this?

@gvanrossum Packaging specifications are handled somewhat differently, see here.

Having said that, I do think that there needs to be more discussion on Discourse before this becomes a PEP change, and my initial feeling is that I'd actually rather see this change as the prompt to move the reference spec for wheels from the PEP into https://packaging.python.org/specifications/, freezing PEP 427 as a historical document.

But I need more time to think through the implications here so this PR shouldn't be merged yet.

From what I understand, setuptools and pip don't implement escaping like the PEP currently says, and probably never have. A lot of packaging specifications are write-ups of existing de-facto standards defined by the main tools, and far more people look at what pip & setuptools do than what a PEP says. So even as the maintainer of a tool which does follow the written spec, I'm not particularly surprised or disappointed that it's the written spec that would change in a situation like this.

Let's take further discussion back to Discourse, here.

For information, historically PEP 427 was the canonical definition of how wheels worked, the tools were built from the spec (unlike, as @takluyver mentioned, many other packaging specs which are write-ups of existing practices). Unfortunately, though, we weren't as experienced writing specs when PEP 427 was written, so it's a lot more "informal" than later ones, and as such needs tidying up and pinning down in some areas (the fact that we've managed to not need more revisions than we have is both a credit to the original work, and a result of us pulling out specifics of more complex areas into their own PEPs).

The escaping part of the wheel spec was written before most of the other standards, and I suspect it was mostly a practical concession to make sure that splitting on dashes worked. With the exception of project name, more recent standards provide better normalisation rules that (luckily!) still allow splitting on dashes. IMO, we should therefore defer to other specs when we can for normalisation rules. See my discourse post for more details.

Okay, it's up to @pfmoore to merge this if and when it's to his liking. I'll unsubscribe.

I'm closing this for now since an actual decision has not been reached yet.